|
A software licensing audit or software compliance audit is an important sub-set of software asset management and component of corporate risk management. When a company is unaware of what software is installed and being used on its machines, it can result in multiple layers of exposure.〔(【引用サイトリンク】title=Software License Management )〕 The primary benefits a corporation receives from performing a software licensing audit are greater control and various forms of cost savings. The audit is used both as an efficiency mechanism to improve software distribution within an organisation and as a preventative mechanism to avoid copyright infringement prosecution by software companies. Software licensing audits are an important part of software asset management, but also serve as a method of corporate reputation management by ensuring that the company is operating within legal and ethical guidelines. Software audits should not be confused with code audits, which are carried out on the source code of a software project. == Challenges == If the auditing company self-dependently scans the code base, one of the serious challenges is the license changes between versions. Some software libraries start with one license and later switch into another. The typical examples are switching from the single permissive license to the dual licensing model (the choice between strong reciprocal or paid commercial) as for iText, switching from more reciprocal to more permissive license (as for Qt Extended) and opensourcing the previously commercial code (as for OpenJDK). In such cases it is not enough to detect that some library or code fragment has been used - an exact used version must be correctly identified. Further difficulties may arise if the library owner removes the obsolete versions (that were under different license) from the public sources. Some licenses (like LGPL) have very different conditions for the simple linking and creating of the derivative works. In such case the proper audit must take into consideration if the library has been linked or the derivative work (custom branch) has been created. Finally, some software packages may internally contain fragments of the source code (such as source code of the Oracle Java) that may be provided only for reference or have various other licenses, not necessary compatible with the internal policies of the company. If the software team actually does not use (or even is not aware) about such fragments, this must be viewed differently from the case if they would be directly linked. All these issues are relatively easy to resolve if the auditing group cooperates with the software team that normally should know the used versions and so on. If the software team is not trusted, an incompetent audit may find many "inconsistencies" and "violations" where there are not any. 抄文引用元・出典: フリー百科事典『 ウィキペディア（Wikipedia）』 ■ウィキペディアで「software licensing audit」の詳細全文を読む スポンサード リンク
|